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Abstract 

We present four new history sniffing attacks. Our attacks 
fit into two classical categories—visited-link attacks and 
cache-based attacks—but abuse new, modem browser fea¬ 
tures (e.g., the CSS Paint API and JavaScript bytecode 
cache) that do not account for privacy when handling 
cross-origin URL data. We evaluate the attacks against 
four major browsers (Chrome, Firefox, Edge, and IE) and 
several security-focused browsers (ChromeZero, Brave, 
FuzzyFox, DeterFox, and the Tor Browser). Two of our at¬ 
tacks are effective against all but the Tor Browser, whereas 
the other two target features specific to Chromium-derived 
browsers. Moreover, one of our visited-link attacks (CVE- 
2018-6137) can exfiltrate history at a rate of 6,000 URLs 
per second, an exfiltration rate that previously led browser 
vendors to break backwards compatibility in favor of pri¬ 
vacy. We hope that this work will lead browser vendors 
to further reconsider the design of browser features that 
handle privacy-sensitive data. 

1 Introduction 

Browsing history can reveal a lot about a person: their 
age, gender, location, political leanings, preferred adult 
sites—even who they are in the real world [57, 58]. And 
one user’s browsing history can spill other users’ secrets, 
thanks to social networking websites like Facebook and 
Linkedln [53], Anyone who touches a search bar should 
care about safeguarding this sensitive data. 

In principle it should be straightforward; after all, the 
web platform provides no direct means for JavaScript 
to read out a user’s history. In practice, things get more 
complicated. Browsers still allow web developers to per¬ 
form a restricted (and occasionally dangerous) set of com¬ 
putations on history data. For example, using the CSS 
: visited and :link selectors, developers can condition¬ 
ally style a link based on whether its destination URL 
appears in the user’s browsing history. And what a devel¬ 


oper can do, an attacker can do too—so browsers must 
account for all kinds of abuse, like exploiting CSS selec¬ 
tors as side channels to “sniff" a URL for visited status. 

As early as 2002, attackers discovered ways of de¬ 
tecting whether a : visited selector matched a given 
link element; by pointing the link’s destination to a URL 
of interest, they could leak whether a victim had vis¬ 
ited that URL [4—6, 10, 23]. Many popular websites put 
these attacks into production, actively profiling their vis¬ 
itors; a developer could even purchase off-the-shelf his¬ 
tory sniffing “solutions” [24]. Once browsers closed these 
holes, attackers discovered that they could abuse different 
browser features, like the MozAfterPaint event or the 
requestAnimationFrame API, to steal the same data, or 
could use : visited selectors to trick their victims into 
giving information away [5,49,57]; attackers also learned 
to leak history information through timing channels based 
on browsers’ caching of embedded resources (e.g., images 
or scripts) [7, 14, 53], 

In response, browser vendors continue to plug leaks ad- 
hoc, as they are discovered. At the same time, they rush to 
support new features and new APIs to accommodate new 
classes of applications, from video games to IoT to virtual 
and augmented reality. Of course, to ensure that new ap¬ 
plications run with reasonable performance, browser ven¬ 
dors also continuously add new caches and optimizations. 
This increasingly complex piping introduces more joints 
from which history data may leak—from the CSS Paint 
API to the JavaScript bytecode cache—and on-demand 
plumbing won’t keep up with the flow forever. 

In this paper we present new history sniffing attacks that 
abuse the complexities of modern browsers. We demon¬ 
strate: (1) three visited-link attacks, abusing new browser 
features which give attackers a range of capabilities to 
operate on sensitive history data, from executing arbitrary 
JavaScript code in the rendering pipeline with the CSS 
Paint API [50], to composing complex graphical com¬ 
putations using CSS and SVG; and (2) a cache-timing 
attack that abuses Chrome’s new JavaScript bytecode 


cache [18]. We evaluate our attacks against four major 
browsers (Chrome, Firefox, Edge, and Internet Explorer) 
and five security-focused browsers (ChromeZero, Brave, 
FuzzyFox, DeterFox, and the Tor Browser). Two of our 
attacks target features specific to the Chrome family of 
browsers while the other two are more general. Our at¬ 
tacks can exfiltrate history data on all browsers except the 
Tor Browser, and our attack on the CSS Paint API even 
does so at the high rate of 6,000 URLs per second. To our 
knowledge, this is the fastest visited-link attack since Jane 
and Olejnik’s 2010 attack [23]; Google assigned the new 
attack CVE-2018-6137 and awarded a $2,000 bounty. 

While browser vendors have already begun to plug 
these individual leaks, new features and caches will con¬ 
tinue to allow attackers to steal sensitive information. This 
need not be the case. Much like browsers enforce the 
same-origin policy (SOP) in a principled way—ensuring 
that one origin 1 cannot read sensitive data from another 
origin—they could similarly build architectural protec¬ 
tions around history data. As first a step in this direction, 
we propose to (1) associate the referring origin with all 
persistent URL data, including history and cache entries, 
and (2) only expose this data to code—whether web appli¬ 
cations or core browser components—running on behalf 
of the same origin. 

In the next section, we give a brief review of his¬ 
tory sniffing and related work. Then, we describe our 
attacks and the browser features that enable them: the 
CSS Paint API (Section 3.1), CSS 3D Transforms (Sec¬ 
tion 3.2), fill-coloring SVG images (Section 3.3), and 
the JavaScript bytecode cache (Section 4). In Section 5 we 
evaluate these attacks on different browsers, and describe 
a principled approach to eliminating them altogether. 

2 Background and related work 

Browsers keep track of the URLs that their users visit 
in order to (1) help those users recognize sites that they 
have already visited (e.g., by marking familiar links with 
a different color), and (2) speed up browsing by caching 
resources to avoid network requests. Unfortunately, web 
attackers [1] can exploit this saved state to learn users’ 
private browsing habits. We describe two such history 
sniffing attacks below. 

Visited-link attacks Browsers let developers style links 
according to history data: a developer can use the CSS 
: visited selector to write style rules that only apply to 
link elements pointing to previously-visited URLs. For 


1 Origins are the security principals of the web, designated by 
protocol-host-port triples (e.g., https://www. example. com: 443). For 
brevity, we elide the protocol and port throughout the paper. 


example, the following CSS rules color links blue when 
unvisited and purple otherwise: 

/* Default link color to blue: */ 

a { color: blue; } 

/* Turn visited links purple: */ 

a:visited { color: purple; } 

Through JavaScript, a developer can query any 
element’s computed style properties by calling its 
getComputedStyle method, which returns data such as 
{color: "purple"}. Previously, calling this on a link 
element styled as above directly leaked whether or not 
the user had visited that link’s destination URL [10]. 
Browsers also permitted targeting arbitrary styles to vis¬ 
ited links with the : visited selector: based on a link’s 
(secret) visited status, an attacker could permute its ap¬ 
pearance with CSS in ways the attacker could then ob¬ 
serve through JavaScript. 

In response to real-world history sniffing attacks of 
this kind [12, 24], major browsers adopted a pair of miti¬ 
gations [4, 5, 46, 57]. First, they addressed explicit leaks 
through getComputedStyle by lying about the computed 
style of a link: the method now always returns the unvis¬ 
ited version of the link’s style. Second, they addressed 
implicit leaks by limiting : visited link styling to colors— 
which are supposed to be unobservable by JavaScript— 
and updating browser layout engines to cache links’ com¬ 
puted styles where possible, in place of re-calculating 
them, in an effort to avoid timing attacks. 

Weinberg et al. [57] demonstrated that these mitigations 
are not enough—that web attackers can still creatively 
leak history information. They used interactive tasks (e.g., 
CAPTCHAs) to trick users into disclosing history infor¬ 
mation, inferred the color of links from screen reflec¬ 
tions in webcam images, and used re-paint events—at the 
time directly exposed to JavaScript—to observe when a 
link’s visited status changed according to an update of 
its destination URL. After browser vendors responded 
by removing the functionality exposing re-paint events to 
JavaScript, Paul Stone showed how attackers could still de¬ 
tect re-paints through a straightforward timing attack [49]. 
Our work continues in this tradition, using a variety of 
modern browser features to build new visited-link attacks 
which ar efast (leak the visited status of many URLs per 
second), reliable (work across different browsers and op¬ 
erating systems), invisible (conceal their presence), and 
automated (require no special interaction from the vic¬ 
tim). 

Browser-cache attacks Browsers rely on many layers 
of caching to speed up web applications; by caching a 
resource like an HTML document or a video, browsers 
avoid the overhead of re-fetching that resource the second 



time a user visits a page. Most browsers use only the re¬ 
source URL to index cache entries, and do not take into ac¬ 
count the origin of the page embedding the resource [22]. 
As Felten and Schneider showed in 2000 [14], this allows 
a web attacker at https : //evil . com to perform a cross¬ 
origin request to https : //f b . com, say, and to learn if the 
user has visited the other site by measuring the duration 
of that request. The request is faster if the resource from 
https://fb.com is already in the cache, and slower if 
the browser must fetch it over the network—measurably 
so, if the target resource is sufficiently large. 

Van Goethem et al. [53] show how more recent browser 
features—the Application Cache [54] and Service Work¬ 
ers APIs [43]—can also leak history data and other private 
user information. Kim et al. [27] use the Quota Man¬ 
agement API [59] for similar attacks; these efforts are 
part of a broader class of web privacy cache-based at¬ 
tacks [7, 15, 17, 31, 32, 40, 41, 44, 56, 58]. We present 
our own cache-based attack, with particularly strong re¬ 
liability, precision, and applicability to a wide range of 
target sites. 


3 Visited-link attacks on history 

In this section we describe three related attacks on vis¬ 
ited links that reveal user browsing history to an at¬ 
tacker. These “re-paint” attacks each exploit a funda¬ 
mental vulnerability in how modern browsers handle 
visited links: by forcing the browser to re-paint accord¬ 
ing to a link’s visited status and measuring when re¬ 
paint events occur, an attacker can learn whether or not 
the URL pointed to by the link has been visited. At¬ 
tackers can detect the visited status of arbitrary, exact 
URLs, including path information (so they can distin¬ 
guish https://usenix.org/conference/woot-201 8 
from https: //usenix. org). Moreover, they can do this 
without being perceived by the victim. 

3.1 Abusing the CSS Paint API 

First, we show how an attacker can sniff history data us¬ 
ing the CSS Paint API. The CSS Paint API, introduced 
in 2018, lets websites hook into the browser’s rendering 
pipeline and draw parts of HTML elements themselves— 
for example, to fill the background of a web page with 
a repeating checkerboard pattern that adapts to any win¬ 
dow size and display resolution. By detecting when these 
hooks are invoked, an attacker can observe when the 
browser re-paints a link element on the page. Toggling 
a link between destination URLs causes the link to be 
re-painted if its visited status changes, so the attacker can 
infer whether or not those URLs have been visited. 


Background The CSS Paint API allows a developer 
to plug dynamically-generated graphics into any context 
where CSS would normally accept a static image [50]. 
It does so using “paint worklets” (or “paintlets”), small 
JavaScript programs that run in their own, self-contained 
execution contexts. Paintlets all contain a paint callback, 
a JavaScript function that accepts as arguments a handle 
to a drawing canvas, the desired image dimensions, and 
a read-only set of properties and their values. To create 
the checkerboard background we mentioned above, the 
developer makes a paintlet with a paint callback that 
loops through the canvas width and height to draw evenly- 
spaced squares. Within the paintlet script, they then use 
the registerPaint function to associate their paintlet 
with a custom identifier like checkers. Then, in their 
CSS file, the developer sets the page’s background image 
to paint(checkers), where paint is the CSS command 
for referencing a paintlet. Now the browser will show 
the checkerboard pattern when a user navigates to the 
developer’s page, and if the user re-sizes the window, the 
pattern will automatically adjust to fit. This is because, for 
each element the checkers paintlet is set up to draw, the 
browser invokes the paintlet’s paint callback whenever 
it detects a “paint invalidation” on that element: any event 
that might change how the canvas is rendered (e.g., when 
the element is initially created or when its dimensions 
change). 

Attack An attacker can use the CSS Paint API to 
observe whether a URL was visited by (1) crafting a 
link element that gets re-painted only if its associated 
URL is visited and (2) using a timing channel (leak¬ 
ing information through the timing of browser opera¬ 
tions) to determine whether the re-paint took place. Sup¬ 
pose an attacker wants to determine if a victim has vis¬ 
ited https://ashleymadison.com. First, the attacker 
chooses a dummy link that they know the victim has 
not visited (e.g., https://dummy.com; or a randomly- 
generated URL). The attacker then creates a link element 
pointing to the dummy destination and sets the link’s 
background image to be rendered by a paintlet: 

<a id="target" href="https: //dummy. com”>link</a> 
<style> 

tftarget {background-image: paint(myEvilPainter);} 
</style> 

When the browser initially draws the link, it will invoke 
myEvilPainter’s paint callback. 

Later, in a normal (non-paintlet) script, the attacker 
switches the link’s destination to the actual target 
URL (without changing the displayed link text): 
target.href = "https://ashleymadison.com". If 
neither the dummy, known-unvisited URL nor the target 


URL appear in the victim’s history, the link’s visited 
status starts at false and stays that way after switching 
its destination. However, if the target URL does appear 
in the victim’s history, then the link’s visited property 
changes to true — causing a paint invalidation on the 
link element. The paint invalidation forces the browser 
to re-paint the link, and thus invoke myEvilPainter’s 
paint callback for a second time. 

Counting the calls to the paint callback tells the at¬ 
tacker whether or not the target URL has been visited 
by the victim: two calls indicates visited, and one call, 
unvisited. Counting these invocations is difficult, however, 
because paintlets run in their own separate context, with 
a minimal set of capabilities: they cannot make network 
requests, communicate with other scripts, or use most 
other APIs typically available to JavaScript. Moreover, 
browsers ensure that the pixels they draw cannot be read 
back through JavaScript, and even prevent paintlets from 
preserving state across multiple executions [47]. 

Despite these constraints, the attacker can detect 
browser re-paints using an event-loop timing channel [56]. 
Specifically, in the paint callback, they introduce a 
loop that runs for twenty milliseconds and blocks the 
JavaScript event loop. Since the event loop is shared, code 
running in the page can directly observe this: 

var start = performance.now(); 

II ... change link URL & block on paintlet's paint 
II callback ... 

var delta = performance.now() - start; 
if (delta > threshold) { 

alert( 'Victim visited Ashley Madison!'); 

} 

The longer delta indicates that the change from dummy 
URL to target URL caused a re-paint, which in turn means 
that the victim visited the target URL. 

We note that re-paints (e.g., as triggered by an attacker) 
are not instantaneous — they are queued and handled when 
the browser renders the “next” frame [38]. Since today’s 
browsers render web pages at a (target) speed of 60 frames 
per second, this puts an upper bound on the rate of re¬ 
paints—and thus the bandwidth (rate of URLs tested per 
second) of re-paint attacks. Using a single target link, for 
example, means that our attack can—at best—exfiltrate 
60 URLs per second. 

Amplified attack We consider an alternative, amplified 
attack that uses multiple link elements, each pointing 
to a different target URL. 2 This attack consists of two 
phases: (1) a record phase that uses a paintlet to scan tar¬ 
get URLs and stow away their visited statuses by abusing 

2 We find using 1,024 links at a time provides optimal bandwidth. 
The attacker can feed a longer list of target URLs through their set of 
link elements in batches of 1,024, allocating each link one target URL 
per re-paint. 


the registerPaint function; and (2) an exfiltrate phase 
that uses another paintlet to “read” the visited status bits 
and communicate them—via a CSS covert channel—to 
a normal, non-paintlet attacker script. We describe these 
two phases below. 

Record. In this phase, the attacker first generates 
a unique identifier string for each target URL (e.g., 
ashleyMadison for https: //ashleymadison. com). As 
in our previous attack, the attacker then sets the back¬ 
ground of each link element to be rendered by a paintlet. 
But, in this attack, the paint callback does not block 
the event loop to leak the visited status of the URL. 
Instead, the callback uses registerPaint to associate 
the paintlet with a new identifier: the old identifier suf¬ 
fixed with _visited. This ensures that if the victim 
visited https: //ashleymadison. com, for example, the 
ashleyMadison_visited identifier is associated with a 
paintlet — but not otherwise. In the exfiltration phase we 
use this to leak the visited status of the URL. 

We note that although the attacker could create a paint¬ 
let for each URL, with a different identifier baked into 
the code of each paintlet, our record phase only needs a 
single paintlet: 

paint (ctx, geometry, properties) { 

// Get identifier (e.g., ashleyMadison): 
var iden = properties.get(' font-family '); 

// Associate this paintlet with tweaked 
// identifier (e.g., ashleyMadison_visited): 
registerPaint( ${iden}_visited' , ...); 

} 

By setting the CSS font-family style of a link to the 
URL identifier, the attacker can communicate to the 
paint callback which URL the re-paint is running on 
behalf of and avoid creating thousands of paintlets. 

Exfiltrate. After feeding all the target URL batches 
through their set of link elements, the attacker cre¬ 
ates a new paintlet to check which possible *_visited 
identifiers were registered—corresponding to the set 
of visited target URLs. To this end, the paintlet calls 
registerPaint with each possible identifier. If the iden¬ 
tifier has already been registered (during the record phase), 
registerPaint throws an exception to complain about 
the duplicate call. The paintlet catches these exceptions 
and, for each already-registered identifier, registers a new 
unique identifier based on the old: 

try { 

// Try to associate identifier 
// (e.g., ashleyMadison_visited): 
registerPaint(iden, ...); 

} catch (e) { 

// Create new identifier from the old 
// (e.g., ashleyMadison_exfiltrate): 
var newlden = iden. replace( ' ..visited' , 

'_exfiltrate'); 



// Associate new identifier with paintlet: 

registerPaint(newIden, ...); 

} 

For example, if the identifier ashleyMadison_visited 
was registered in the record phase, this paintlet will now 
additionally register ashleyMadison_exfiltrate. 

The attacker detects these new paintlet identifier reg¬ 
istrations using a quirk of the CSS Paint API implemen¬ 
tation. Right before creating the “exfiltrate” paintlet, the 
attacker inserts a series of elements into the page—one 
per possible *_exf iltrate identifier—styling each with 
CSS of the following form: 

#ashleyMadison_element:: after 
{ content: paint(ashleyMadison_exfiltrate); } 

This CSS code selects the HTML element with iden¬ 
tifier ashleyMadison_element and inserts a new im¬ 
age element as its last child (via the :: after “pseudo¬ 
element” selector feature [34]). To draw this image, 
the content rule specifies that the browser should in¬ 
voke the paint callback of the paintlet registered to the 
ashleyMadison_exf iltrate identifier; the browser gets 
around to handling this after the attacker’s “exfiltrate” 
paintlet runs. And now, the quirk: if this paintlet identifier 
was just registered, then the browser calculates a large 
width value for the child image element. Otherwise—if 
ashleyMadison_exf iltrate was not just registered, or 
was not registered at all—the image element gets a small 
width. The attacker can loop back through the *_element 
elements and check their widths: a large width corre¬ 
sponds to a visited URL. 

Evaluation Our amplified attack can probe a user’s 
browsing history at 6,000 URLs per second without the 
victim noticing, i.e., we can scan Alexa Internet’s list of 
Top 100,000 Websites [2] in around 17 seconds—in the 
background, with no visible effect on the page, and with 
no interaction required from the victim. 3 This rate is com¬ 
parable to the original : visited attacks that led browser 
vendors to break backwards compatibility in order to ad¬ 
dress them [6]. 

Google Chrome is the only browser that has imple¬ 
mented the CSS Paint API, so it is also the only browser 
affected by this attack; we successfully performed the 
attack on Chrome 66.0.3359.117 under Windows, ma- 
cOS, and Ubuntu Linux. In response, Google assigned 
CVE-2018-6137 to our report and rewarded a $2,000 bug 
bounty. Their patch for the Chrome 67 release includes 
an interim fix that disables the CSS Paint API on link 
elements and their children. 

“tile Alexa list compresses down to only 650 KB, compared to the 
median compressed web page size of 1500 KB [21], leaving plenty of 
room for even longer target URL lists to be downloaded to victims’ 
browsers without arousing suspicion. 



Figure 1: Examples of CSS transform on an image element: 
first, rotating it 45 degrees clockwise in the 2D plane; then, 
rotating it 45 degrees clockwise around its vertical (Y) axis. 

3.2 Abusing CSS 3D transforms 

Our attack using paintlets showed how browsers leak his¬ 
tory when JavaScript hooks directly into the rendering 
pipeline, but attackers can also exploit more indirect leaks 
in web page rendering. The next attack takes advantage of 
CSS 3D transforms, which developers can use to translate, 
rotate, project, and even animate HTML elements in a 
three-dimensional space [19, 28, 30]. An attacker stacks 
these 3D transforms on top of other CSS effects to cre¬ 
ate a link element that the victim’s browser struggles to 
draw. Then the attacker repeatedly toggles the link ele¬ 
ment between two different destination URLs and, using 
the : visited selector, forces the browser to complete 
expensive re-paint operations when the link changes vis¬ 
ited status. The presence of these re-paints leaks whether 
the destination URLs were visited by the victim, informa¬ 
tion that the attacker harvests by monitoring the page’s 
rendering performance through JavaScript. 

Background As of CSS version 3, developers can mark 
up HTML elements with transformations [36]. To rotate 
an image 45 degrees clockwise, two-dimensionally, the 
developer would write this CSS transform mle: 

#photo { transform: rotateZ(45deg) ; } 

They can even embed multiple commands in a sin¬ 
gle transform rule by specifying an ordered list of 
transformations for the browser to apply. Adding the 
perspective() command further enables 3D transforma¬ 
tions, like rotateY(), which rotates an element around 
its vertical axis: 

#photo 

{ transform: perspective(100px) rotateY(45deg) ; } 

Figure 1 shows the results of these transformations. They 
can even be combined with other CSS post-processing 
effects: the filter rule, for example, offers contrast, sat¬ 
uration, drop-shadow, and other visual adjustments one 
would expect to find in photo-editing software [35]. 

Attack As in Section 3.1, an attacker wish¬ 
ing to detect whether their victim has visited 
https://ashleymadison.com first creates a link 
pointing to a known-unvisited dummy URL (e.g., 









https : //dummy. com). Then the attacker takes advantage 
of CSS 3D transforms and other post-processing effects 
to increase the burden on the browser when it re-draws 
the link: 

#target { 

transform: perspective(100px) rotateY(37deg) ; 
filter: 

contrast(200%) 

drop-shadow(16px 16px 10px #fefefe) 

saturate(200%) ; 

text-shadow: 16px 16px 10px #fefffe; 
outline-width: 24px; 
font-size: 2px; text-align: center; 
display: inline-block; 

color: white; 
background-color: white; 
outline-color: white; 

} 

We experimented with different effects to come up with 
the formulation above, which includes filter, shadow, and 
outline styles; in our implementation of the attack, we 
also fill the link’s display text with a long random string 
of Chinese characters. The specific combination of proper¬ 
ties is less important than the idea that the attacker makes 
the element difficult for the browser to render by layering 
on computationally intensive effects. 

The attacker wants to force the victim’s browser to redo 
these computations when the link’s visited status changes. 
A modern browser will perform them once—albeit rela¬ 
tively slowly—when it initially draws the link, and then 
reuse the rendered result unless the link’s computed style 
changes. But the attacker can tie the link’s computed style 
to its visited status via the CSS : visited and :link se¬ 
lectors. This should be the end of the road for this attack: 
in 2010, browser vendors limited these CSS selectors to 
only support style rules related to color change, in order 
to prevent Clover’s original visited-link attack. The fix 
works because simply changing an element’s color should 
be too quick for JavaScript to detect under normal cir¬ 
cumstances [46]. In this case, though, changing the link’s 
color means that the browser has to redo all the expensive 
transformations and post-processing effects that the at¬ 
tacker applied on top of the link element. So the attacker 
writes a : visited style for the link specifying a different 
set of color values for when its visited status is true: 

a:visited { 
color: 

background-color: 

outline-color: 

} 

Next, the attacker toggles the link’s des¬ 
tination URL from https://dummy.com to 


https://ashleymadison.com via JavaScript, as 
in Section 3.1’s attack. Suppose the victim has, in fact, 
visited https://ashleymadison.com. Changing the 
link’s destination switches its visited status from false 
to true, which in turn changes its color values from 
white to near-white (thanks to the : visited styles); as a 
result, the victim’s browser must re-draw the link from 
scratch with the new colors. The particular color choices 
here make the link invisible to the victim when placed 
against a white background, and the change from white 
to near-white is similarly imperceptible; the link could 
even be hiding in the background of this paper, and the 
reader would be none the wiser. 

Swapping the link’s destination URL once—toggling 
its visited status—causes the victim’s browser to perform 
a costly computation, holding up the page’s rendering 
cycle while it completes. Doing so repeatedly —ping- 
ponging back and forth between https://dummy.com 
and https: //ashleymadison. com —causes paint perfor¬ 
mance for the containing page to drop significantly (but 
not for the rest of the browser, or for scrolling, thanks to 
modern browsers’ parallel, multi-process architectures). 
If the attacker measures this performance drop, they learn 
that their victim is an Ashley Madison user. On the other 
had, if https://ashleymadison.com is unvisited like 
https://dummy.com, then swapping the link between 
these destination URLs doesn’t change its visited status, 
doesn’t change its color values, doesn’t force the victim’s 
browser to repeat the expensive rendering computations— 
and doesn’t yield a corresponding drop in the page’s paint 
performance. 

To harvest from this leak, the attacker needs to mon¬ 
itor the overall paint performance of the page while 
they repeatedly toggle their link’s destination URL; there 
are many ways to accomplish this from JavaScript. We 
chose to use the requestAnimationFrame API, an API 
intended to allow JavaScript code to drive fluid anima¬ 
tions. When a developer passes a callback to this func¬ 
tion, the browser invokes the callback right before paint¬ 
ing the next frame for the page. Browsers aim to in¬ 
voke the callback about sixty times per second (the same 
as the page’s overall frame rate) but will fall behind 
if paint performance for the page drops [38]. The at¬ 
tacker can take advantage of this by taking two mea¬ 
surements, each over a fixed time window. First, the 
attacker takes a control measurement c for oscillating 
between two different known-unvisited dummy URLs 
(e.g., https://dummy.com and https://dummy2.com). 
The attacker gathers c by cyclically registering call¬ 
backs to requestAnimationFrame and recording the 
number of times the browser invokes them. Then, using 
the same procedure, the attacker takes the experimental 
measurement e for oscillating between the target URL 
https: //ashleymadison. com and the dummy. An e sig- 


nificantly lower than c reflects the paint performance drop 
that the attacker is looking for, signifying that the victim 
has visited https: //ashleymadison. com. 

One could imagine a mitigation for this attack that sim¬ 
ply avoids re-calculating a link element’s style based on 
a change in destination URL alone; however, this mitiga¬ 
tion would be ineffective. In an alternate version of this 
attack, the attacker leaves the link’s destination URL con¬ 
stant, pointing to https://ashleymadison.com, while 
rapidly toggling the colors in the : visited style rules 
via JavaScript. If https://ashleymadison.com is vis¬ 
ited, this technique produces the same effect as before: 
the link’s color values rapidly change, triggering expen¬ 
sive re-draw operations. If it is unvisited, the color val¬ 
ues of the link remain set to those specified outside the 
: visited styles. The end result is still the same: the paint 
performance leaks the user’s history. 


Evaluation We find our attack effective in up-to-date 
versions of Chrome, Firefox, Edge, and Internet Explorer, 
on Windows, macOS, and Ubuntu Linux; vendors as¬ 
signed our bug reports high- and medium-priority se¬ 
curity classifications. Running the attack on a visited 
URL (e.g., https://ashleymadison.com) causes 70- 
80% fewer requestAnimationFrame callbacks to fire 
when compared to an unvisited URL like dummy. com. We 
are able to perform the attack with a measurement win¬ 
dow of 100ms, producing measurements on the order of 
4 callback invocations versus 15. This suggests that an 
attacker using an intelligent search strategy could quickly 
test many URLs of interest. As mentioned in the attack 
description, the right color choices make the HTML ele¬ 
ments used by the attack invisible to the victim against 
the page background, and the drop in paint performance 
exploited would generally only show up as a slow-down 
of any animations embedded in the containing page. 

The most similar attack to this is Paul Stone’s 2013 
visited-link attack [49]. His attack follows a more tradi¬ 
tional timing attack structure, where the attacker (1) either 
changes a link’s destination once or inserts a group of link 
elements into the page, (2) measures the time of the next 1- 
4 rendered frames, and (3) checks for any delay caused by 
the browser re-painting the link(s) as visited [49]. Testing 
this attack on the same browsers and operating systems 
as our attacks, we find it still works in Firefox on macOS 
and Linux (not Windows)—a testament to the difficulty of 
plugging these leaks. Our attack makes this challenge yet 
more difficult: instead of timing the duration of a single 
re-paint, our attack forces many (expensive) re-paints and 
measures the effect on the page’s frame rate. 


3.3 Abusing fill-coloring of SVGs 

Even without CSS 3D transforms, we can still tie the vis¬ 
ited status of a link to expensive rendering operations; 
here, we use SVG images and the CSS fill rule. The 
SVG format describes an image as a series of declara¬ 
tive component parts—rectangles, circles, drawing paths, 
gradients—that browsers rasterize (render to pixels) as 
needed. An SVG image embedded in a web page scales 
to arbitrary sizes and display resolutions automatically, 
without loss of quality [33]. From the containing page, a 
developer can use CSS to reach into an SVG image and 
style elements within it—most notably, change their fill- 
color with the fill style rule [37]. Applying such color 
updates to complex SVG images becomes very expensive 
for the rendering engine. 

Attack An attacker embeds a complicated SVG image 
inside a link element and sets a series of CSS fill rules 
under : visited selectors, specifying different color val¬ 
ues for the image’s components depending on the link’s 
visited status: 

<a href="https ://dummy. com"> 

<svg xmlns=”http: //www.w3. org/2000/svg”> 

... embedded SVG image data (verbose XML) ... 

</svg> 

</a> 

In our attack, we construct an SVG image that is ex¬ 
tremely expensive to render: the image consists of many 
(7,000+) complex path elements—color-filled polygons— 
arranged in multiple layers. A more clever attacker can 
use an SVG image that optimizes the attack bandwidth. 

Next, the attacker sets up a series of CSS fill rules tar¬ 
geting their SVG image, followed by another series using 
the : visited selector on the containing link—applying 
one color pattern when the link’s visited status is true 
and another when it’s false: 

a svg * {fill: #ffffff;} 
a svg *:nth-child(3n+1) {fill: #fffffe;} 
a svg *:nth-child(3n+2) {fill: #fffeff;} 

a: visited svg * {fill: #feffff;} 

a: visited svg *: nth-child(3n+1 ) {fill: #fefffe;} 

a: visited svg *: nth-child(3n+2) {fill: #fefeff;} 

The color values were selected so that the SVG image is 
invisible on a white background, and so that swapping 
between the two color patterns is imperceptible to the 
victim. 

The remainder of the attack proceeds exactly as in Sec¬ 
tion 3.2: the attacker uses JavaScript to rapidly switch 
either the link’s destination URL or the color values of 
the : visited style rules, in order to force many expen¬ 
sive re-paint operations in the case that their chosen target 


URL (e.g., https: //ashleymadison . com) has been vis¬ 
ited by the user. Simultaneously, the attacker monitors 
the overall rendering performance of the page (e.g., with 
requestAnimationFrame) and compares it with a con¬ 
trol measurement to infer the visited status of the URL. 

Evaluation This attack is successful against Chrome, 
Firefox, Edge, and Internet Explorer, and was reported 
to vendors together with the attack in Section 3.2. As in 
Section 3.2, we can make visited determinations over a 
measurement period of 100ms (on the order of 2 callback 
invocations versus 5). The signal grows more and more 
powerful with longer periods (9 versus 41 at 1000ms, for 
example). Here, too, the attacker hides elements used in 
the attack from their victim by picking color values which 
blend in with the page background. 

4 Bytecode-cache attacks on history 

Beyond the visited-link mechanism—at the root of the 
attacks described so far—other modern browser features 
also leak history data. Browser optimizations that share re¬ 
sources between origins (e.g., caches) may let an attacker 
probe these resources for traces left behind by pages of 
different origins. In particular, we examine Chrome’s 
JavaScript bytecode cache (added in 2015). This cache 
retains the bytecode generated by the JavaScript engine 
when it compiles and runs a script. If the script must be 
executed again later, the JavaScript engine can use the 
cached bytecode instead of re-compiling the script [18]. 

By probing the bytecode cache, an attacker can reli¬ 
ably determine whether a victim’s browser has previously 
executed a particular script file—therefore inferring de¬ 
tails of the victim’s browsing history. In fact, the attacker 
can detect past script executions even after the victim 
restarts their browser or machine, since Chrome persists 
its bytecode cache to disk. 

Background Say a developer embeds the script f oo. j s 
on their website. When a user visits the developer’s web¬ 
site, their browser downloads f oo. j s, but cannot immedi¬ 
ately begin executing it. The browser must first parse the 
JavaScript code in foo. js (since scripts are distributed 
in source form), and then compile it to bytecode suitable 
for driving the JavaScript engine. This initial “boot up” 
phase eats up a big chunk of time thanks to JavaScript’s 
flexible syntax and semantics. Moreover, if the developer 
embeds foo. j s across multiple pages of their website, 
the performance cost gets worse and worse. With every 
click and page load, the browser repeats the same work to 
boot up foo. js. 

Chrome avoid this repeated work with its “bytecode 
cache” optimization, which targets repeatedly-executed 


scripts exceeding a predefined size threshold [18, 42]. If 
foo. j s fits this description, then upon executing it for the 
third time. Chrome’s JavaScript engine will stow away 
the generated bytecode to an on-disk cache entry keyed 
by foo. js’s URL. For subsequent executions. Chrome 
skips the usual boot up phase and reads the bytecode from 
cache. 

Attack Because Chrome shares each script’s byte¬ 
code cache entry between pages of different origins, 
an attacker can infer history information by mea¬ 
suring how long Chrome takes to boot up a given 
script. Imagine that the attacker wants to know whether 
their victim has visited https://ashleymadison.com. 
The attacker selects a script embedded by its home- 
page, e.g., https://ashleymadison.com/foo.js. The 
selected script should be large enough that prior visits to 
Ashley Madison would have caused the victim’s browser 
to generate a bytecode cache entry for the script. Then, 
the attacker invisibly embeds a script tag pointing to 
this URL in their own page at https: //attacker . com: 

<script src=" https://ashleymadison.com/foo. js”> 

</script> 

When the victim visits https: //attacker . com. Chrome 
downloads, compiles, and executes Ashley Madi¬ 
son’s foo.js —unless it can find an entry for 
https://ashleymadison.com/foo.js in its bytecode 
cache, in which case it skips the compilation step. In the 
latter case, foo. j s goes from downloaded to running in 
significantly less time than it would otherwise (on the 
order of tens of milliseconds; see Figure 2). By measuring 
this time difference, the attacker can infer whether the 
victim visited Ashley Madison. 

To accomplish this reliably, the attacker must precisely 
measure two points in time: (1) when the browser fin¬ 
ishes downloading the script and (2) when the script starts 
running; these points bookend the compilation step. The 
attacker must explicitly avoid measuring the time the 
browser spends on downloading foo. j s before compila¬ 
tion and the time it spends executing it afterward—these 
numbers vary based on many factors (e.g., the victim’s net¬ 
work connection), and therefore introduce enough noise 
to obscure the relevant timing signal. To track point 1— 
when the script is fully downloaded—the attacker can use 
the Resource Timing API, which provides a timestamp 
for this event [39]. For point 2—when the script starts 
running—browsers offer no direct means of measurement. 
However, the attacker can approximate the script’s start 
time by measuring the time at which the script first sets a 
global variable. 4 

4 This is possible because most scripts large enough to trigger byte¬ 
code caching tend to contain framework or library code that they intend 
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Figure 2: Boot time for a script embedded by Yahoo’s home- 
page based on how many times it has been executed. Chrome’s 
JavaScript engine creates a cache entry following the third exe¬ 
cution of the script. Times shown are averages of 10 trials. 

Therefore, before carrying out the attack, the attacker 
must identify the name of the first global variable that 
foo. js sets. To this end, the attacker records a list of all 
variables in the JavaScript global scope, i.e., the window 
object: 

var oldGlobals = Object .keys(window); 

Next, they inject a script tag pointing to foo. js, which 
instructs the browser to (1) load and execute the target 
script and then (2) call back into their own code, the 
loadCallback function: 

var scriptTag = document .createElement(' script '); 
scriptTag.async = false; 

scriptTag.src = 'https://ashleymadison.com/foo.js'; 
scriptTag.addEventListener( 'load' , loadCallback); 
document .head.appendChiId(scriptTag); 

In the loadCallback function, the attacker generates a 
new list of global variables and compares this list with 
oldGlobals to identify the name of the first global vari¬ 
able that foo. js sets. 

In the attack phase, the attacker defines a setter func¬ 
tion that is called whenever this global variable is set by 
foo. js. This function simply records the current time 
at its first call—the approximate time the script starts 
running. The attacker uses this timestamp and the down¬ 
load timestamp to compute the script boot time, which 
they compare against a reference measurement to infer if 
the script bytecode was previously cached. As Figure 2 
shows, the bytecode cache can speed up the boot time by 
2.5x-10x, making it easy for the attacker to infer whether 
or not the victim previously visited Ashley Madison. 

Evaluation We find this attack effective against the 
Windows, macOS, and Linux versions of Chrome. We 

for other scripts to use, so they start by initializing a global variable 
where those other scripts will expect to find the code they provide (e.g., 
the popular jQuery library creates a global jQuery variable to hold its 
public functions [25]). 


reported this to Google, who marked our ticket as security- 
sensitive with low priority to fix. The attack takes around 
100ms total to detect a bytecode cache hit or miss for a tar¬ 
get script URL, and can be performed multiple times and 
in parallel to bulk-query the cache for a list of targets (e.g., 
to scan the Alexa Top Sites [2] and construct a profile of 
the victim). An attacker can learn more information about 
their victim with a smarter selection of target scripts—for 
example, testing scripts which are only loaded for logged- 
in members of a site. All the while, the victim remains 
unaware of the running attack, as it involves no visible 
components. 

In an automated scan, we confirm the presence of a 
suitable target script—of 100 KB or more in size, before 
compression—on 372 of the top 500 sites (74%). We 
consider this a strict lower bound for the number of web¬ 
sites vulnerable to our bytecode cache attack, as we only 
scan for script files embedded statically by each website’s 
FITML source. For performance reasons, some sites dy¬ 
namically inject their scripts after the initial page load [3]; 
though bytecode cache entries are still generated for such 
scripts, and the attack works on them without modifica¬ 
tion, our scanning tool does not yet detect dynamically 
injected scripts. Additionally, around 32 of the remaining 
sites detected as untargetable were either CDN domains 
which do not serve web pages or had certificate errors that 
prevented us from testing them. 

Compared to cache-timing attacks on other web re¬ 
source types (e.g., images), our attack is more practical 
since it cuts out some sources of noise (e.g., from net¬ 
work variability): timing the compilation of a JavaScript 
file produces a more stable measurement than timing im¬ 
age downloads. Moreover, the required file size threshold 
to produce a detectable time difference is much smaller, 
enabling the attacker to target a wide range of websites. 

As with most history-sniffing cache-timing attacks, our 
attack is destructive: the process of querying for a byte¬ 
code cache entry forces the creation of said entry if it 
did not already exist. This means the attack cannot be re¬ 
peated against the same script URL for the same victim. 

5 Consequences and defense 

We test in Chrome and Firefox on three operating sys¬ 
tems (Windows, macOS, and Ubuntu Linux), and in Edge 
and Internet Explorer, which are Windows-only. Two 
of our attacks—the CSS Paint API attack (Section 3.1) 
and the bytecode cache attack (Section 4)—only affect 
Chrome, since they target features not yet implemented 
in other browsers. The other two attacks—involving CSS 
3D transforms (Section 3.2) and SVG fill-coloring (Sec¬ 
tion 3.3)—use more traditional features and prove effec¬ 
tive across all four of these browsers. Finally, for compari¬ 
son, we test two separate implementations of Paul Stone’s 







visited-link attack [48, 55], and find it only successful in 
Firefox on macOS and Linux, as previously mentioned. 

In addition to testing the stock versions of major 
browsers, we also evaluate our attacks against these 
browsers with additional privacy features enabled and 
against several privacy-oriented browsers: 

► Chrome with Site Isolation. Site Isolation [51] con¬ 
fines data for each origin in a separate process but 
does not place any restrictions on : visited selec¬ 
tors or the bytecode cache, which remain shared 
across isolation boundaries. As a result this feature 
does not prevent our attacks. 

► ChromeZero research extension. ChromeZero tries 
to thwart attackers by limiting certain JavaScript 
APIs [45]. Since our attacks don’t rely on these APIs, 
they still work, even with the extension in its highest 
protection mode. 

► Brave. Brave is a security- and privacy-oriented 
browser. But since Brave is built atop Chromium, 
we find it to be vulnerable to the same attacks as 
Chrome. (We only test this browser on macOS.) 

► Firefox with visited links disabled. Turning off Fire- 
fox’s layout.css.visited_links_enabled con¬ 
figuration flag should eliminate visited link styling 
altogether [5, 46]. Not so: disabling the flag fails to 
block either our visited-link attacks or Paul Stone’s 
older one; we reported this bug to Mozilla. 

► The Tor Browser. This Firefox distribution does not 
keep track of user history [52] and is therefore im¬ 
mune to our attacks. 

► The FuzzyFox and DeterFox research browsers. Both 
of these modified versions of Firefox address tim¬ 
ing side channels by reducing the resolution of ex¬ 
plicit and implicit timers; FuzzyFox also normalizes 
when browser events are scheduled [8, 29]. Our two 
Firefox-compatible attacks still work because they 
don't rely on fine-grained timers, but FuzzyFox im¬ 
poses a lOx reduction in our attacks’ exfiltration 
bandwidth. Stone’s visited-link attack fails in both 
browsers. (We only compile these two on Ubuntu.) 

Appendix A summarizes our results in table form. 

Defense To address recurring same-origin policy vio¬ 
lations, browser vendors like Mozilla restructured their 
browser architecture to enforce the SOP by construc¬ 
tion [20]. We argue that they should similarly restructure 
browsers to address history sniffing attacks. To this end, 
we propose a same-origin-style policy to cover persis¬ 
tent data: browsers should not solely use the URL of a 
resource when storing it, but should also associate the 
origin of the page on whose behalf the code is running. 


For example, any history entry should be labeled with the 
origin of the referring page, each bytecode cache entry 
should be labeled with the origin of the page embedding 
the corresponding script, etc. Accordingly, when fetching 
stored data, the browser should check the origin of the 
page performing the lookup—and succeed only if that 
origin is the same as the “referrer-origin” associated with 
the stored data. Our proposal is similar to “domain tag¬ 
ging” [13] and “same-origin caching” [22], updated for 
the modern web. 

This defense, of course, incurs some cost. For the byte¬ 
code cache, initial loads of a script on each origin would 
pay a cache-miss cost—but subsequent page loads would 
still benefit from caching; other caches would incur sim¬ 
ilar costs. To address this, we envision an extension to 
cross-origin resource sharing (CORS) [26] that allows 
popular, public resources (e.g., jQuery) to be safely shared 
across origins. 

Our proposed defense also partially breaks web compat¬ 
ibility. Specifically, CSS : visited selectors would only 
accurately represent whether links have been clicked-on 
from a page of the same origin. But browsers have broken 
compatibility for privacy before: the fix for the original 
: visited leak changed the getComputedStyle API to 
return incorrect information, for example, and broke exist¬ 
ing stylesheets using : visited. Our proposed fix would 
not only entirely replace this previous one but also provide 
robust protection against future attacks—even attacks that 
rely on user interaction [57]. 

6 Conclusion 

Protecting browsing history is crucial to user privacy. The 
four attacks in this paper show that modern browsers 
fail to systematically safeguard browsing history data 
from web attackers; various browser features allow at¬ 
tackers to leak this data, in some cases at alarming rates. 
These attacks are, as a group, effective against all ma¬ 
jor browsers as well as several privacy-focused designs, 
across all three major operating systems. We propose a 
systematic solution to protecting browsing history data 
with a same-origin-style policy. Although this would in¬ 
cur minor performance costs and a small change to the 
behavior of visited link styling, we believe that these costs 
are worth the benefit to user privacy. 
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A Summary of results 
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Chrome (with Site Isolation) 
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Firefox (no visited links) 

- 

/ 

/ 

- 

y Linux, macOS / X Win 

FuzzyFox [16, 29] 
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We evaluate our attacks and two existing attacks against all major browsers and several research prototypes. Checkmarks (/) indicate 
an attack was successful, while cross-marks (X) indicate that an attack failed. We test our attacks across three operating systems: 
Windows 10 Pro Version 1709 (OS Build 16299.371) with Chrome 66.0.3359.117 (with and without ChromeZero), Firefox 60.0.1, 
Edge 41.16299.402.0, Internet Explorer 11.431.16299.0, and Tor Browser 7.5.6; macOS 10.10.5 with Chrome 65.0.3325.181, Firefox 
60.0.1, Tor Browser 7.5.6, and Brave 0.22.727; and Ubuntu Linux 18.04 with Chromium 66.0.3359.181, Firefox 60.0.1, Tor Browser 
7.5.6, FuzzyFox, and DeterFox. 



